home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000061_icon-group-sender _Sat Oct 17 09:18:43 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  2KB

  1. Return-Path: <icon-group-sender>
  2. Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63])
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA11645
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Sat, 17 Oct 1998 09:18:43 -0700 (MST)
  5. Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA08300; Sat, 17 Oct 1998 09:18:42 -0700
  7. To: icon-group@optima.CS.Arizona.EDU
  8. Date: Fri, 16 Oct 1998 08:37:32 GMT
  9. From: r.raschke@quadstone.com (Robby)
  10. Message-Id: <F0wvyK.DC0@cogsci.ed.ac.uk>
  11. Organization: Quadstone Limited
  12. Sender: icon-group-request@optima.CS.Arizona.EDU
  13. References: <Pine.LNX.3.96.981013093657.8760A-100000@katto.kaapeli.fi>
  14. Reply-To: r.raschke@quadstone.com
  15. Subject: Re: A problem with sets
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18.  
  19. In article <Pine.LNX.3.96.981013093657.8760A-100000@katto.kaapeli.fi>,
  20.     Kimmo Kettunen <kettunen@kaapeli.fi> writes:
  21. > Hello,
  22. [...]
  23. > During the stem synthesis I have pretty many string variables which may be
  24. > altered during the process. Part of the variables are unnecessary and
  25. > redundant, and to prune the results I put them all in the end into a set
  26. > structure to get rid of redundant ones. Works fine, results are OK.
  27. > BUT: now I do not know excactly, which variables I get out of the set as I
  28. > see only the results, string values of the variables.
  29. [...]
  30. > Kimmo
  31.  
  32. Hmm, you could use a table (aka associative array) instead. Say you
  33. have a bunch of variables a to z, you can build a table indexed by
  34. the variable values having the name of the variable as the associated
  35. value:
  36.  
  37.    mytable := table(0)
  38.    mytable[a] := name(a)
  39.    ...
  40.    mytable[z] := name(z)
  41.  
  42. Since indices are unique, you'll always end up with a string being
  43. associated with the last variable that contained the string that you
  44. added to the table, eg. if a and b contain the same string the value of
  45. mytable[a] and mytable[b] will be "b" after the above statements.
  46. variable("b") gets you back to the original variable, eg.
  47. variable(mytable[a]) = b
  48.  
  49. I didn't test any of this.
  50.  
  51. Robby
  52.  
  53.